The present invention relates to telecommunication networks, and more particularly to systems and methods for controlling network server message flow to prevent server overload.
Telecommunications services are coming to rely more and more on real time network servers. In the traditional telephony arena, Service Control Points (SCPs) have been translating "freephone" numbers (800 numbers in the U.S.A.) into real telephone numbers for years. SCPs will soon support a range of intelligent network services, such as voice activated dialing, local number portability, calling name delivery and other screening features, automated telephone polling, and personal communications services. These services increase the demand on SCPs and require SCPs to handle transactions that vary widely in the number of messages per transaction and their real time costs. An analogue of the SCP for video dial tone services is a Level 1 Gateway. In a video dial tone network a Level 1 Gateway screens video session requests and instructs other network elements to set up connections. Level 1 Gateways also handle multiple transaction types, e.g., session requests for interactive TV and for pay-per-view events.
Service demand volatility threatens the integrity of the services that such network servers provide. In an environment of rapid service introduction, ordinary traffic engineering may not keep pace with the growth and fluctuations in load placed on network servers. The servers may experience occasional or even frequent overloads. Overload controls must therefore complement engineering practices.
Prior art controllers implement a trial and error search to establish proper control values relating measurements taken by the controller to server workload capacity. Examples of such measurements include the number of messages that flow into the server, the number of messages that encounter excessive response times, and processor utilization.
The prior art search algorithms suffer from two major limitations. First, the search algorithms update control parameters on a much longer time scale than arriving transactions (seconds vs. a few milliseconds). As a result, convergence of the total transaction rate to a desired value can be slow.
Second, some of the measurements the server uses to trigger controls, such as the number of incoming messages and the number of messages encountering excessive delay, are difficult to relate to the server workload capacity. For example, the amount of time the server needs to process a message varies considerably, so the number of incoming messages alone does not indicate the load on the server. Similarly, when messages encounter excessive delay, it is not obvious how to use counts of such messages to take control actions, especially when transactions span multiple measurement intervals.
When a server determines that it is in overload, it must instruct traffic sources to reduce the number of new transactions to the server. A source is a logical grouping of transactions; one source is the smallest stream of translations subject to a single overload control request. Present controllers in SCPs tightly couple the way servers specify the amount of traffic reduction to a technique for reducing traffic.
SCPs block incoming calls with Automatic Code Gapping ("ACG"), illustrated in FIG. 1. In ACG, the source blocks all new transactions 1 that occur during a gap interval 3. When the gap interval has finished, the next incoming new transaction, 5, 6, or 7, will be accepted. Immediately following the acceptance of the new transaction, the next gap interval begins. Thus, an ACG request to a source tells it to initiate at most one new transaction per "g" seconds, where g is the gap interval.
Conventional gapping techniques store predetermined tables of gap intervals at the sources. In response to congestion, the server transmits to the source an "overload level," an index into the table. The source then applies the gap corresponding to the overload level.
A limitation of this type of controller is that the fixed list of values may not contain the proper control values necessary to remedy a given server overload condition. A controller that is restricted to selecting a control value from a fixed list exhibits characteristic oscillations in transaction throughput as the server alternately selects overload levels that are too large and too small. The larger the mismatch between the values on the fixed list and the values actually needed to control the overload, the larger the swings in throughput. The frequency of the oscillations is governed by the length of the measurement interval, since the controller picks a new value from the list once per interval.
Conventional gapping techniques tend to yield less than optimal throughput because they tend to turn traffic on and then off for too long. Additionally, because applying conventional gapping the server transmits the same indices to all the sources of a given service type, large, high traffic sources tend to be throttled more severely than low traffic sources.
There is, therefore, a need for a method of controlling message flow to prevent server overload that overcomes the limitations of conventional techniques. For example, network server overload controllers should reduce the load incoming to the server to the maximum level it can comfortably handle. In a multi-service environment, a controller should also block demands for individual services provided by the network server.